System and method for processing hardware or service usage data

ABSTRACT

A data processing system and method are disclosed. In an embodiment, the data processing system preferably maintains a plurality of substantially continuously available data processing service instances. The plurality of data processing service instances may be aggregated into groups of one or more instances of like data processing services. A service control manager is also preferably provided as an individual service running on the system and is operable to organize, manage and maintain the various service instances as well as other aspects of the data processing system. The service control manager preferably also cooperates with the individual services of a message queue manager, a service queue manager and an application services manager to effect the efficient distribution and processing of received data as well as perform other system management operations.

TECHNICAL FIELD OF THE INVENTION

[0001] The present invention relates generally to computer processingand, more particularly, to a high-volume data processing system andmethod.

BACKGROUND OF THE INVENTION

[0002] Many data processing systems operate according to rules-basedmanagement systems. The typical product of rules-based systems is asingle data processing model containing comprehensive logic thatrepresents all of the business rules for a particular line of business.Further, one consequence of such a program structure is that as eachtransaction or data record is received for processing, the comprehensiveprogram will typically need to evaluate each business rule to determineits applicability to the current transaction or data record beforeperforming any processing operations. As a result, processingtransaction records becomes very hardware intensive and highlyinefficient, especially in those rules-based program structures adaptedto accommodate a wide variety of transaction record types. Whilerules-based management systems do provide for the easy incorporation ofadditional business logic, they typically do not achieve the levels oftransaction or data record throughput desired and demanded by mosthigh-volume data processing operations.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A more complete understanding of the present embodiments andadvantages thereof may be acquired by referring to the followingdescription taken in conjunction with the accompanying drawings, inwhich like reference numbers indicate like features, and wherein:

[0004]FIG. 1 is a schematic drawing generally depicting a dataprocessing system incorporating teachings of the present invention anddeployed in cooperation with a telecommunications network;

[0005]FIG. 2 is a flow diagram depicting one embodiment of a method foroperating a service-based architecture in a data processing systemaccording to teachings of the present invention;

[0006]FIG. 3 is a flow diagram illustrating one embodiment of a methodfor implementing a service control manager in a service-basedarchitecture according to teachings of the present invention;

[0007]FIG. 4 is a flow diagram illustrating one embodiment of a methodfor launching a service control manager according to teachings of thepresent invention; and

[0008] FIGS. 5-8 are flow diagrams illustrating one embodiment of amethod for operating a service control manager in a service-basedarchitecture according to teachings of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0009] Preferred embodiments of the present disclosure and itsadvantages may be best understood by referring to FIGS. 1-8 of thedrawings, wherein like numerals are used for like and correspondingparts of the various drawings.

[0010] Referring first to FIG. 1, a diagram depicting one environment inwhich teachings of the present invention may be implemented is shown. Inone aspect, the present invention is directed to enhancing theefficiency with which a high volume data processing system can processdata, for example, telecommunications hardware or service usagetransaction records. However, teachings of the present invention may beemployed in data processing environments other than telecommunicationssystems including, but not limited to, retail transaction systems,accounting systems, point-of-sale systems, shipping systems, datacaching systems, as well as others.

[0011] In a telecommunication system such as that illustrated generallyin FIG. 1, the present invention may be employed to processtelecommunication hardware or service usage transaction records fromsuch sources as POTS (plain old telephone system) telephone 103,wireless telephone 106, wireless communications enabled PDA (personaldigital assistant) 109 as well as computer system 112. Computer system112 may communicate via a wireless or wireline Internet 113 as well asvia other means. POTS telephone 103, wireless telephone 106 and PDA 109may also be operable to communicate via Internet 113.

[0012] In typical operation, when POTS telephone 103, wireless telephone106, PDA 109 or computing system 112 is employed or used in itsrespective communicative capacity via Internet 113, wirelinecommunications 115, or wireless communications 118, one or moretelecommunications hardware or service usage transaction records may berecorded by a telecommunications service provider. Telecommunicationswitches 121, or a computing component operating therewith, in a typicaloperating scenario, preferably accumulates the telecommunicationshardware or service usage transaction records generated in response tothe use of one or more of communication devices 103, 106, 109 or 112.Once a number of transaction records have been accumulated, or apredetermined reporting time has arrived, for example,telecommunications switch 121 or a computing component cooperatingtherewith preferably sends the accumulated records via batchtransactions transmission 127 to one or more of data processing systems124. Alternatively, instead of awaiting batch transaction transmission127, one or more of data processing systems 124 may request or otherwiseobtain the batch transaction records 127 from telecommunications switch121. The transfer of data between telecommunications switch 121 and oneor more of data processing systems 124 may be implemented via Internet113, wireline communications 115, wireless communications 118, or othercommunication technologies, according to teachings of the presentinvention.

[0013] As commonly employed, telecommunication switch 121 is responsiblefor handling large volumes of telecommunication hardware or serviceusage transaction records. With respect to the batch transaction recordtransmission indicated generally at 127, data processing systems 124 aretypically responsible for processing large quantities of transactionrecords from a defined set of transaction record types. According toteachings of the present invention, the efficiency with which dataprocessing systems 124 process such large volumes of telecommunicationtransaction records may be enhanced by implementing, executing orotherwise maintaining a plurality processing services where each of theprocessing service instances is dedicated or specifically adapted toprocessing selected ones of the defined transaction record type set.

[0014] Although illustrated as tower computers, data processing systems124 may assume a variety of forms. For example, data processing systems124 may include a plurality of rack servers. In general, data processingsystems 124 will preferably include one or more processor, memory, atleast one communications port, one or more user input devices, one ormore displays, as well as other components. Examples of data processingsystem 124 manufacturers include, but are not limited to, DELL, HewlettPackard, Sun Microsystems and Apple.

[0015] In one embodiment of the present invention, as illustratedgenerally at 130, data processing systems 124 may enhance the efficiencywith which they process transaction records or other data through theimplementation of a service-based architecture. A service-basedarchitecture may be defined as a data processing operation implementedsuch that it deploys a plurality of data processing service instances,where the service instances are dedicated to the processing of one ormore selected transaction record types. One example of a service-basedarchitecture implementation incorporating teachings of the presentinvention is depicted generally at 133 of FIG. 1.

[0016] Service-based architecture implementation 133, according toteachings of the present invention, preferably includes a servicecontrol manager 136 generally operable to supervise, manage or otherwisemaintain the plurality of dedicated transaction record type processingservice instances running or executing on data processing system 124. Inoperation, service control manager (SCM) 136 preferably cooperates with,employs or otherwise implements the preferred functionality of one ormore message queue managers (MQM) 139, service queue managers (SQM) 142and one or more service application management modules (SVC) 145.

[0017] As mentioned above, the present invention preferably implements aservice-based architecture in that a plurality of individual servicesmake up the processing architecture. Specifically, SCM 136, MQM 139, SQM142 and SVC 145 are each preferably services forming a portion of theservice-based architecture. Further representing the service-basedarchitecture of the present invention is the implementation, in oneembodiment, of a plurality of service instances each of which preferablyincludes all of the logic necessary to process a selected transactionrecord type, e.g., 911 transaction records, directory assistancetransaction records, credit card transaction records, etc. In a furtherimplementation, the transaction record processing service instances maybe adapted to process a limited plurality of selected transaction recordtypes where the limited plurality of transaction record types requiresubstantially similar processing logic.

[0018] In a further aspect, as discussed herein, the service orprocessing objects of the present invention may be accumulated intolike-type groups or groupings. For example, one or more 911 transactionrecord processing service instances may be organized into a singlegroup. It is these grouping for which the message queue management andservice queue management functions discussed herein may optimally beemployed. By organizing groups of one or more service instancesaccording to like-type transaction record processing capabilities, dataprocessing system 124 may more readily adapt to changing workloads byadding or subtracting service instances to or from the group. These andother aspects of the present invention will be discussed in greaterdetail below.

[0019] In a preferred embodiment, each SVC 145 preferably includes aminimum number of service instances 148 dedicated or configured toprocess selected transaction record types. For example, SVC 145 maydesire to maintain at least three (3) instances of a dedicatedtransaction record type service adapted to process 911 emergency calls,a minimum number of service instances dedicated or adapted to processtransaction records resulting from directory assistance calls, one ormore service instances for processing calls placed during peak/off-peaktimes, as well as service instances dedicated to the processing of othertransaction record types.

[0020] Further, the one or more service instances 148 dedicated orconfigured to process one or more selected record types may each operatein accordance with an operating schedule. As such, in one aspect, havingone or more service instances that remain substantially continuouslyavailable suggests that such service instances remain substantiallycontinuously available within their scheduled time slots of operation.

[0021] For example, service instances operable to process transactionrecords of type ‘E’ may be scheduled to execute or run Monday throughFriday during the hours of 6:00 AM to 7:00 PM, while service instancesoperable to process transaction records of type ‘F’ may be scheduled torun every Thursday during the hours of noon to 6:00 PM. Therefore,during the Monday through Friday, 6:00 AM to 7:00 PM, the serviceinstances operable to process transaction records of type ‘E’ arepreferably monitored and otherwise maintained such that they remainsubstantially continuously for the desired period.

[0022] In further embodiments, selected service instances may bescheduled to run monthly, bimonthly, semi-annually, annually, etc., aswell as not to run on selected dates or not to run on selected recurringdates. Each of the successive scheduled service instances is preferablyassigned a priority to ensure its preferred processing. As will bediscussed in greater detail below, the scheduling of the various serviceinstances as well as any associated priority processing is preferablymaintained by SCM 136.

[0023] In the event a transaction record is received for which a serviceinstance 148 is not currently active, available or running, SCM 136, MQM139, SQM 142 and/or SVC 145 may be adapted to initiate a transactionrecord processing service adapted to process the record type. Thetransaction record processing service may be called upon receipt of suchtransaction records, according to a defined schedule, in response toaccumulation of a number of such transaction records, or otherwise.

[0024] SQM 142, in one aspect of the present invention, is preferablyadapted to adjust or otherwise manage one or more service queuesassociated with a corresponding service instance 148. Service queues maybe defined as queues which are operable to maintain for processingtransaction records received from a message queue associated with thegrouping of like-type transaction record processing service instances.Among the operations preferably effected by SQM 142 is the balancing ofqueued transaction records across or among the active service instancesavailable for processing the specific transaction record types, e.g.,across the grouped instances of 911 transaction record processingservices. SQM 142 may be further adapted to perform additionaloperations.

[0025] MQM 139 preferably cooperates with SQM 142, in part, to furtherincrease the efficiency with which the various service instances processqueued transaction records. Among other operations, MQM 139 preferablyprepares, readies or otherwise initiates one or more services adapted tomanipulate the message queues associated with the one or more groups orgroupings of service instances directed to processing a selectedtransaction record type. In one aspect, MQM 139 may be adapted toprioritize messages, e.g., transaction, service instance cancellationmessages, etc., within associated service queues MQM 139 may also beadapted to initiate additional service instances in response to abacklog in one or more message or service queues, as well as to executeor cancel other services according to a service schedule. Further detailregarding the operation and cooperation of SCM 136, MQM 139, SQM 142 andSVC 145 will be discussed below.

[0026] In the telecommunication transaction record processing systemexample of FIG. 1, data processing system 124 may be employed to performone or more preprocessing operations. For example, the batch transactionrecords processed by data processing systems 124 may subsequently bepassed on to a billing statement process or other subsequent transactionrecord processing operation 154.

[0027] Referring now to FIG. 2, a flow diagram illustrating oneembodiment of a method for implementing a service-based architecture isindicated generally at 200. According to teachings of the presentinvention, implementation of a service-based architecture preferablyincludes maintaining a plurality of service instances operable toprocess selected types of transaction records. Preferably, the pluralityof service instances are available on one or more of data processingsystems 124, as indicated at 203, on a substantially continuous basis.For example, one or more of data processing systems 124 maysubstantially continuously execute or run one or more telecommunicationservice or hardware usage transaction record processing services foreach of transaction record types ‘A’-‘M’, for a total of (n) record typeservices.

[0028] At 206, a service-based architecture incorporating teachings ofthe present invention preferably enables the queuing of transactionrecords according to transaction record type to a queue associated witha respective dedicated transaction record type processing serviceinstance or grouping of service instances. For example, each type ‘E’transaction record will preferably be queued to a message or servicequeue associated with a group having one or more service instancesdirected or dedicated to processing type ‘E’ transaction records.

[0029] At 209, when a transaction record type processing group orgrouping includes a plurality of service instances, the presentinvention preferably enables the queued transaction records to bebalanced across or among the plurality of service instances such thatmore efficient data processing may be achieved. Initial balancing andbalancing as-needed generally enhances the efficiency with which dataprocessing system 124 manages the service instances it maintains andcompletes it designated tasks.

[0030] At 212, the queued transaction records may be processed inaccordance with their associated transaction record processing service.Upon completion of the processing operations, the processed transactionrecords may then pass to one or more subsequent operating centers, suchas a billing operations center 154 of FIG. 1.

[0031] As mentioned above, the present invention may be employed in avariety of data processing systems. In one possible system,telecommunications system 100, transaction records may be created andreceived in a variety of formats. One format which is typically producedin a telecommunications system such as system 100 is the AutomatedMessage Accounting (AMA) format from Telecordia and is employed by mosttelecommunications carriers. Other formats, such as EMI (ExchangeMessage Interface) records, may also be employed with the presentinvention. Further, the present invention may be employed with othertransaction record formats, such as a format developed to trackdownloads or other operations performed by computer 112 via Internet,private network or other network connections 113.

[0032] Referring now to FIG. 3, a flow diagram depicting one embodimentof a method for implementing SCM 136 is shown. In method 300 of FIG. 3,after initialization of data processing system 124 at 303, SCM 136 maybe launched at 306. Additional details regarding the launch of SCM 136are discussed with reference to FIG. 4.

[0033] Once SCM 136 has been launched, method 300 preferably proceeds to309 where one or more service instances currently or recently operatingon data processing system 124 may be recovered, preferably by SCM 136.After completing its recovery operations, SCM 136 preferably enters itsnormal operating mode at 312.

[0034] SCM 136 may be configured such that it returns to 309 or 312after completing its normal operating procedures at 315. Alternatively,SCM 136 may be adapted to rest or sleep for a predetermined period afterthe passing of which it may return to a prior operation, e.g., 309 or312, in method 300. Additional detail regarding the launch, recovery,and normal operating mode of SCM 136 will be discussed in greater detailbelow with respect to FIGS. 4-8.

[0035] In general, FIGS. 4-8 disclose one embodiment of a preferredoperating cycle of a data processing system incorporating teachings ofthe present invention. It should be understood that FIGS. 4-8 primarilydiscuss one method but that many variations in may be made withoutdeparting from the spirit and scope of the present invention.

[0036] Referring now to FIG. 4, one embodiment of the operationspreferably associated with the launch of SCM 136, are shown generally at400. As illustrated in FIG. 4, after the launch of SCM 136 at 403,method 400 may proceed to 406 where SQM 142 is preferably launched.

[0037] In one embodiment, SQM 142 preferably includes one or moreservices which may be called from SCM 136 or from one or more other dataprocessing system 124 services. The services included in SQM 142 arepreferably operable to manipulate, maintain or otherwise manage one ormore service queues associated with the active or existing transactionrecord processing service instances. In addition, the services of SQM142 may also be adapted to provide information regarding one or moreaspects of the transaction record processing service queues. Forexample, one ore more services of SQM 142 may be operable to determinethe number of transaction records remaining in a service queue,determine the throughput of a service queue as well as perform otheroperations.

[0038] At 409 of method 400, MQM 139 may be launched. According toteachings of the present invention, MQM 139 preferably includes one ormore services which may be called from SCM 136 or from one or moretransaction record processing service instances. The one or moreservices included in MQM 139 are preferably adapted to manipulate orprovide information regarding the one or more message queues associatedwith the groupings of or individual service instances running in theservice-based architecture of the present invention.

[0039] In one aspect, MQM 139 is preferably operable to prioritizetransaction records queued for processing. For example, MQM 139 may beenabled to reorder a message or service queue to cause prioritydesignated transaction records to be processed first and the remainingtransaction records to be processed according to a FIFO(first-in-first-out) or other method. In another aspect, MQM 139 may beadapted to initiate additional service instances if it is determinedthat the number of transaction records in a service or message queue fora given record type service group exceeds a desired performanceparameter. More detail regarding the operation and cooperation of SCM136, MQM 139, SQM 142 and SVC 145 is described below.

[0040] SVC 145 may be launched at 412 of FIG. 4. MQM 139, SQM 142 and145 may be launched in any order or substantially simultaneously,according to teachings of the present invention. SVC 145 preferablyincludes one or more services that may be called upon to serve one ormore transaction record processing needs of data processing system 124.Each of the services included in SVC 145 preferably include all of thelogic necessary to process the transaction record types associated witha particular service. After the launch of MQM 139, SQM 142 and SVC 145,method 400 preferably proceeds to method 500 of FIG. 5.

[0041] Beginning at 503, after launch or initiation as described above,SCM 136 preferably initiates and effects the recovery of any stalledservice instances. A stalled service instance may include, but is notlimited to, those service instances which have ceased processing forreasons other than a command to terminate. Recovery of a stalled serviceinstance may involve restarting the service instance and its associatedservice queue, removing any unprocessed transaction records from theinstance's service queue for processing by another service instance aswell as performing other operations. Upon completion of stalled serviceinstance recovery at 503, method 500 preferably proceeds to 506.

[0042] At 506, SCM 136 preferably effects the recovery of any terminatedtransaction service instances. Terminated services instances which SCM136 may desire to recover include, for example, any service instances orqueues which were terminated before completing processing of one or morequeued transaction records. Other definitions of recovered terminatedservices instances may be employed in the present invention. Inaddition, other termination events may be addressed and recovered by SCM136. Upon completion of terminated service instance recovery at 506,method 500 preferably proceeds to 509.

[0043] At 509, SCM 136 preferably begins a process of verifying allexisting or active service instances. As mentioned above, there is apreference that a data processing system 124 operating in accordancewith teachings of the present invention maintain, in addition to SCM136, MQM 139, SQM 142 and SVC 145, a minimum number of service instancesadapted to the processing of one or more selected transaction recordtypes, running or executing substantially continuously. Accordingly, at509, SCM 136 preferably determines the number of active instances ofeach transaction record service type currently available on dataprocessing system 124.

[0044] For each type of transaction record service instance counted at509, SCM 136 preferably compares the total number of such active serviceinstances to its respective preferred minimum number of serviceinstances selected to remain substantially continuously available ondata processing system 124 at 512. If it is determined that the totalnumber of active instances of the particular transaction type serviceunder evaluation matches the preferred minimum number of such serviceinstances selected to remain substantially continuously available at512, method 500 preferably proceeds to 515. If it is determined at 512that the number of active instances of the current transaction typeservice is below the preferred number of service instances for suchservice type, method 500 preferably proceeds to 518. Finally, if it isdetermined at 512 that too many active instances of the current servicetype are available, method 500 preferably proceeds to 521.

[0045] At 518, in response to too few instances of a particulartransaction type service, SCM 136 will preferably initiate an additionalnumber of transaction record service instances to bring the number ofactive service instances into accordance with the preferred minimum.Following initiation of the additional transaction record serviceinstances at 518, method 500 preferably proceeds to 515.

[0046] Alternatively, at 521, in response to a determination of too manyactive service instances of a given type, SCM 136 may initiate thecancellation of one or more of the excess service instances. Once anappropriate number of transaction record service instances have beencancelled at 518, method 500 preferably proceeds to 515.

[0047] At 515, a determination may be made, preferably by SCM 136, as towhether all types of currently available or active transaction recordservice instances have been reviewed for their compliance with theirrespective preferred minimums. In the event all types of currentlyavailable transaction record service instances have not been reviewed,method 500 preferably returns to 509 where the next group of instancesof a particular transaction record service type may be evaluated for itscompliance with a corresponding number of service instances preferablysubstantially continuously available. Alternatively, if it is determinedat 515 that all currently available service types have been reviewed fortheir compliance with their respective preferred numbers of activeservice instances, method 500 preferably proceeds to 524.

[0048] At 524, SCM 136 may determine whether each of the transactionrecord service types selected to remain substantially continuouslyavailable on data processing system 124 is active and/or available. Ifit is determined at 524 that each of the dedicated transaction recordservice types selected to remain substantially continuously availableare not currently available, method 500 preferably proceeds to 527 wherethe preferred minimum number of instances for a currently unavailabletransaction record service type may be identified. Proceeding then to530, the minimum number of service instances for the unavailable servicetype identified at 527 may be activated, initiated or otherwise madeavailable. Upon initiation of the currently inactive transaction recordservice instances at 530 or upon the determination at 524 that each ofthe transaction record service types selected to remain substantiallycontinuously available is made, method 500 preferably proceeds to 533.

[0049] At 533, operation of the queues, message and/or service,associated with each of the groupings of one or more transaction recordservice instances may be paused or placed on hold. Holding each of thequeues associated with the dedicated transaction record service instancegroupings may occur substantially simultaneously, substantiallysequentially, or otherwise. Once each of the queues has been paused orplaced on hold, any queued transaction records may be balanced ordistributed across the service instances of each corresponding servicetype grouping at 536. As mentioned above, queue management may beeffected by SQM 142 or MQM 139, preferably as instructed or coordinatedby SCM 136. Further, in holding or pausing the service or messagequeues, processing by the service instance of a current transactionrecord may also be paused, be permitted to complete or continueunabated.

[0050] After balancing or redistribution of the queued transactionrecords at 536, the service instances designated for cancellation at 518may be appropriately cancelled at 539. Cancellation of one or moreservice instances may occur, for example, by SCM 136 inserting in aservice queue associated with each service instance to be cancelled acancellation instruction whereby the service instance will be cancelledor ended upon completion of its current service queue load and thesubsequent processing of the cancellation instruction. Other methods forcanceling a service instance may be employed without departing from thespirit and scope of the present invention. Upon redistribution orbalancing of the queued transaction records and the insertion of anydesired cancellation instructions at 536 and 539, respectively, thequeues are preferably released such that processing of the transactionrecords may resume at 542.

[0051] Following release of the queues and the return to processing ofthe service instances, SCM 136 preferably updates a service registry toindicate each instance, type and other information regarding theservices running on data processing system 124 at 545. As suggested, aservice registry operating in accordance with the service-basedarchitecture of the present invention may track the varied types ofservice instances active on data processing system 124, the number ofinstances in each service type grouping, a termination status for one ormore service instances or groups, when one or more service instances orgroups will awake from a sleep state, as well as other information.After updating the service registry as desired at 545, SCM 136preferably proceeds to 548 where it may loop, sleep or remain in a waitstate until its next processing period, event or occurrence.

[0052] From loop or wait state 548, upon arrival of the next SCM 136processing period, method 500 preferably proceeds to 551 where it may bedetermined whether data processing system 124 is in a recovery mode,other than the ‘recovery mode’ which occurs at initialization, or itsnormal operating mode. If it is determined that data processing system124 is in a recovery mode, such as a recovery mode resulting from one ormore system malfunctions, software updates, etc., method 500 preferablyreturns to 503 where SCM 136 may begin its service recovery operations.Alternatively, if it is determined that data processing system 124 is ina normal operating mode, method 500 preferably proceeds to method 600 ofFIG. 6.

[0053] In one embodiment of the present invention, as will be discussedbelow, the ‘normal operating mode’ of data processing system 124 and SCM136, as depicted generally in FIGS. 6, 7 and 8, repeats or includes manyof the operations preferably performed during the ‘recovery mode’illustrated generally at 500 in FIG. 5. It should be understood thatoperations other than those of the recovery mode 500 may be incorporatedinto a ‘normal operating mode’ without departing from the spirit andscope of the present invention.

[0054] At 603 of method 600, SCM 136 preferably identifies thosededicated transaction record service types selected to remainsubstantially continuously available on data processing system 124. Theservices selected to remain substantially continuously available may bemaintained by a service registry, by setting a bit on one or moreservice calls, in a data file or in another useful by data processingsystem 124 and SCM 136.

[0055] At 606, SCM 136 preferably checks or counts the number of activeinstances for each of the service types selected to remain substantiallycontinuously available. In one embodiment, an active service instancemay be defined as a service instance currently processing one or moretransaction records, a service instance substantially immediatelyavailable to process one or more transaction records or a serviceinstance awaiting receipt of one or more transaction records forprocessing. Other definitions or descriptions of an active serviceinstance may be used without departing from the spirit and scope of thepresent invention.

[0056] At 609, after obtaining an active service instance count at 606,the preferred number of active instances for each service type selectedto remain substantially continuously available may be obtained by SCM136. Subsequently, SCM 136 may also determine whether the number ofactive service instances for each selected service type is in accordancewith the preferred number of service instances for that particularservice type. If it is determined at 609 that the number of activeservice instances for a particular service type is in accordance withthe desired minimum number of service instances, method 600 preferablyproceeds to 612. However, if at 609 it has been determined that thenumber of active service instances for a particular service type is notin accordance with the preferred number of such service instances,method 600 preferably proceeds to 615 where SCM 136 may interrogate dataprocessing system 124 to ascertain the presence of any stalled instancesof the current service type.

[0057] At 612, a determination may be made as to whether all servicetypes selected to remain substantially continuously available have beenverified or checked for their compliance with the preferred number ofsuch service instances. If all selected service types have not beenchecked, method 600 preferably returns to 606 where the next servicetype identified as a service selected to remain substantiallycontinuously available may be evaluated for compliance with itspreferred number of instances. Alternatively, if all selected servicetypes have been evaluated, method 600 may proceed to method 700 of FIG.7.

[0058] At 615, if SCM 136 identifies any stalled instances of thecurrent service type, method 600 preferably proceeds to 618 where SCM136 may initiate recovery of such stalled service instances beforereturning to 609. Alternatively, if it is determined at 615 that thereare no stalled instances of the current service type, method 600 mayproceed to 621 where SCM 136 may interrogate data processing system 124to ascertain whether there exists any improperly terminated instances ofthe current service type.

[0059] If SCM 136 determines at 621 that data processing system 124contains no improperly terminated instances of the current service type,method 600 may proceed to 624 where SCM 136 preferably initiates anappropriate number of instances for the current service type.Alternatively, should SCM 136 identify one or more improperly terminatedinstances of the current service type at 621, method 600 preferablyproceeds to 627 where SCM 136 may initiate the recovery of theimproperly terminated instances.

[0060] Upon initiation of an appropriate number of current service typeinstances at 624, or upon completion of the recovery of any improperlyterminated instances of the current service type at 627, method 600preferably returns to 612 where, as mentioned above, SCM 136 maydetermine whether each of the service types selected to remainsubstantially continuously available has been evaluated. Once allservices selected to remain substantially continuously available havebeen evaluated in accordance with method 600, method 600 preferablyproceeds to method 700 of FIG. 7.

[0061] Illustrated generally at 700 in FIG. 7 is a flow diagramdepicting one manner in which teachings of the present invention mayenhance the efficiency with which data processing system 124 processestransaction records received, for example, from telecommunicationsswitch 121. In general, SCM 136 preferably timely monitors theprocessing operation of each service type grouping to ensure that eachis performing in accordance with one or more system performanceparameters. Accordingly, method 700 can be understood to run assequenced in FIGS. 3-8. Alternatively, method 700 can be understood torun appropriately after receipt of batch transaction transmission 127and upon subsequent distribution or allocation of the transactionrecords to their respective transaction record service type instances ortransaction type groups.

[0062] After receipt and distribution or allocation of the transactionrecords received from telecommunications switch 121, or upon completionof method 600, SCM 136 preferably begins method 700 at 703. At 703, SCM136 may compare the number of transaction records in one or more messageor service queues associated with a selected transaction type servicegroup to a preferred system performance parameter, such as a queuethroughput or queue volume. As mentioned above, MQM 139 and SQM 142 arepreferably adapted to manipulate and provide information on message andservice queues, respectively. If at 703 SCM 136 determines that thenumber of transaction records in a queue associated with a group orindividual instance of a particular dedicated transaction type serviceexceeds a preferred system performance parameter, method 700 may proceedto 706. Alternatively, if SCM 136 determines that the number of queuedtransaction records associated with a particular transaction typeservice group or individual service instance matches or is below thepreferred system performance parameter, method 700 may proceed to 709.

[0063] At 706, SCM 136 may again interrogate data processing system 124to determine whether any stalled or improperly terminated serviceinstances or queues associated with the transaction type underevaluation exist. If one or more stalled or improperly terminatedservice instances, groupings or queues are identified, method 700preferably proceeds to 712 where the improperly terminated or stalledgroups, queues or instances may be recovered before returning to 703. Inan alternate embodiment, upon recovery of any improperly terminated orstalled queues, groups or instance, method 700 may instead proceed from712 to 721 for processing as described below.

[0064] If it is determined at 706 that there exist no stalled orimproperly terminated service queues or instances, method 700 mayproceed to 715 where the total number of active service instancesadapted to process the current transaction type may be compared to apreferred system limit on such service type instances. To avoidstrangling data processing system 124 when an unexpectedly large numberof transaction records of a particular type are received, the presentinvention may incorporate a limit to the number of instances of any oneservice type that may be running at one time. If the maximum number ofallowed service instances is not exceeded at 715, method 700 preferablyproceeds to 718 where one or more additional service instances may beinitiated. From 718, method 700 will preferably proceed to 721.

[0065] At 721, 724 and 727, operations similar to the balancing orredistribution operations discussed above with reference to FIG. 5 maybe effected. Specifically, each of the queues associated with thecurrent service type being reviewed may be paused or held at 721. Oncethe selected queues have been paused or held, the transaction recordsremaining in the queues to be processed may be substantially equallydistributed across each of the active service queues and/or instancesfor the current transaction type at 724. After distribution orbalancing, the queues and service instances may be released for normalprocessing operation at 727. If all service types have been balanced, asdetermined at 733, method 700 may proceed to method 800 of FIG. 8,otherwise, method 700 preferably returns to 703.

[0066] At 709, in response to a queue being in accordance with one ormore system parameters, SCM 136 may compare the number of availableservice instances for processing the current transaction record type toa minimum number of such service type instances selected to remainsubstantially continuously available on data processing system 124. Ifthe number of such available service instances is in accordance with thepreferred minimum, method 700 may proceed to 733 for performance of theoperations described above. However, if it is determined at 709 that thenumber of such service instances exceeds the minimum number of servicetype instances selected to remain substantially continuously available,method 700 may proceed from 709 to 730 where one or more of the serviceinstances may be terminated upon completion of its current processingload. In one aspect, eliminating excess service instances may free upsystem resources such that additional instances of other service typesmay be initiated or such that data processing system 124 may dynamicallyadjust it resource consumption. Method 700 may then proceed to 733 forprocessing as described above.

[0067] In an alternate embodiment of the present invention, beforemethod 700 proceeds from 709 to 730, balancing operations similar tothose performed at 721, holding the queues, and 724, distributing thetransaction records across active service instances and queues, may beeffected. Further, before method 700 proceeds from 730 to 733, abalancing operation similar to that of 727, releasing the held queues,may be performed. Adding operations similar to those of 721, 724 and 727preferably effects the balancing of the transaction record loads in eachqueue associated with each service type instance or service typegrouping. Still other embodiments of method 700 may be incorporated inthe present invention without departing from its spirit and scope.

[0068] Method 800 of FIG. 8 generally illustrates a schedulingcapability preferably implemented by SCM 136 and MQM 139, according toteachings of the present invention. In one embodiment of the presentinvention, SCM 136 may cooperate with MQM 139 to effect as-neededoperation of one or more service types. In an alternate embodiment, MQM139 may perform the bulk of the operations necessary to effect as-neededservice calls. As-needed service operation may include, but is notlimited to, initiating or canceling service instances according to aservice schedule and initiating service instances in response to receiptof one or more transaction types for which a service instance isselected to remain substantially continuously available.

[0069] At 803, SCM 136 or MQM 139 may access a system clock or otherhardware available on data processing system 124 to determine thecurrent time. With a determination of the current time, SCM 136 mayproceed to 806 for the review of a service initiation or cancellationschedule to determine if one or more events are scheduled for execution.Alternatively or in addition, SCM 136 or MQM 139 may consult a queueholding transaction record for which there is no active service instanceavailable.

[0070] If the time has arrived for one or more services to be initiatedor cancelled or a number of transaction records without an activeservice instance available to process them have accumulated, method 800preferably proceeds to 809 where SCM 136 may take the appropriateinitiation or cancellation action. Upon effecting the scheduled eventsidentified at 806 and initiated at 809, or in response to an absence ofscheduled events, method 800 preferably returns to 548 of FIG. 5 whereSCM 136 may loop or pause in a wait state.

[0071] Although the present invention and its advantages have beendescribed in detail, it should be understood that various changes,substitutions, and alterations may be made hereto without departing fromthe spirit and scope of the invention as defined by the followingclaims. For example, the active service instances may be adapted tosleep upon completion of queue processing, queue balancing may beeffected in a manner that takes into account the complexity oftransaction records waiting in each queue, the various benchmarks,metrics, performance parameters, throughput measures, etc., may bepreset values or dynamically determined according to assorted processingcharacteristics over time, data, program or other information refreshesmay be implemented in conjunction with the varied transaction recordprocessing disclosed herein and the data processing system of thepresent invention may be implemented over a number of computer systemsspanning a number of processing centers. Still other alterations arepossible.

What is claimed is:
 1. A method for processing telecommunicationshardware and service usage transaction records, comprising: maintainingsubstantially continuous availability of a minimum number of each of aplurality of service instances, one or more of the plurality of serviceinstances operable to process one of a selected plurality oftelecommunications transaction types; organizing the plurality ofservice instances according to transaction type into service groupingsof one or more service instances; providing a message queue for eachgrouping, the message queues operable to maintain and prioritizereceived transaction records; providing a service queue for each serviceinstance, the service queues operable to maintain transaction recordsfor processing in accordance with the associated service instance;receiving batch telecommunications transaction records; distributing thetransaction records according to transaction type among the messagequeues of the corresponding service groupings; prioritizing, in themessage queues, the transaction records for processing according to atransaction record priority designation; balancing the transactionrecords from the message queues across the service queues associatedwith each service instance in the service grouping receiving transactionrecords; monitoring service grouping performance to determine whetherthe monitored service grouping is performing in accordance with a systemperformance parameter; adjusting the service instances of a servicegrouping failing to perform in accordance with the system performanceparameter; initiating one or more selected transaction record typeservice instances according to a service schedule; queuing transactionrecords for which a corresponding transaction type service instance isunavailable; and initiating at least one service instance correspondingto the queued transactions in response to a queued transactionaccumulation.
 2. A computer readable medium embodying a program ofinstructions, the program of instructions operable to: maintain aplurality of service groups, each service group associated with atransaction type and including one or more service instances adapted toprocess transaction records of the transaction type; queue a batch oftransaction records according to transaction type to a correspondingservice group; balance the transaction records across the serviceinstances of a service group; and process the queued transaction recordsin accordance with each associated transaction type service instance. 3.The computer readable medium of claim 2, further comprising the programof instructions operable to monitor one or more queues associated witheach service group to determine whether the service group is performingin accordance with a system performance parameter.
 4. The computerreadable medium of claim 3, further comprising the program ofinstructions operable to adjust the service instances of a group inresponse to a failure of the group to perform in accordance with thesystem performance parameter.
 5. The computer readable medium of claim4, further comprising the program of instructions operable to re-balancethe queued transaction records across the service instances of anadjusted service group.
 6. The computer readable medium of claim 5,further comprising the program of instructions operable to repeat themonitor, adjust and re-balance operations until each monitored groupperforms in accordance with the system performance parameter.
 7. Thecomputer readable medium of claim 2, further comprising the program ofinstructions operable to monitor one or more queues associated with aservice instance to determine whether the service instance is performingin accordance with a transaction record processing performanceparameter.
 8. The computer readable medium of claim 7, furthercomprising the program of instructions operable to initiate additionalservice instances in response to a failure by the service instance toperform in accordance with the transaction record processing performanceparameter.
 9. The computer readable medium of claim 2, furthercomprising the program of instructions operable to maintainsubstantially continuous availability of a minimum number of selectedtransaction service instances.
 10. The computer readable medium of claim2, further comprising the program of instructions operable to: receive achange to one or more system performance parameters; and implement eachchange real-time such that the changed system performance parameter maybe used in subsequent monitoring of performance.
 11. The computerreadable medium of claim 2, further comprising each service group andassociated service instances adapted to perform substantially allnecessary processing of a selected transaction type.
 12. The computerreadable medium of claim 2, further comprising the program ofinstructions operable to disable a service instance of a service groupin response to identification of excess processing capacity in theservice group.
 13. The computer readable medium of claim 2, furthercomprising the program of instructions operable to restore stalled andimproperly terminated service instances.
 14. The computer readablemedium of claim 2, further comprising the program of instructionsoperable to execute selected service instances in accordance with aservice schedule.
 15. A data processing system, comprising: at least oneprocessor; at least one memory operably coupled to the processor; and aprogram of instructions storable in the memory and executable in theprocessor, the program of instructions operable to maintainsubstantially continuous availability of a plurality of serviceinstances, one or more of the plurality of service instances adapted toprocess at least one of a selected plurality of data types, distributereceived data to the service instances according to data type, adjustthe service instances adapted to process a selected data type inresponse to failure of the associated service instances to perform inaccordance with a system performance parameter and redistribute dataacross the adjusted service instances.
 16. The data processing system ofclaim 15, further comprising the program of instructions operable tobalance the data substantially equally across a plurality of associateddata type service instances.
 17. The data processing system of claim 15,further comprising the program of instructions operable to: organize theservice instances according to data type into groups of one or more; andprovide a message queue for each group operable to receive the data upondistribution.
 18. The data processing system of claim 17, furthercomprising the message queue operable to prioritize the data forprocessing.
 19. The data processing system of claim 15, furthercomprising the program of instructions operable to provide a servicequeue operable to receive and maintain the distributed data for eachservice instance.
 20. The system of claim 15, further comprising theprogram of instructions operable to: monitor service instanceperformance; and initiate at least one additional service instance inresponse to failure of a service instance to perform in accordance witha performance parameter.
 21. The system of claim 15, further comprisingthe program of instructions operable to initiate selected data typeservice instances in accordance with a service schedule.
 22. The dataprocessing system of claim 15, further comprising the program ofinstructions operable to maintain substantially continuous availabilityof a minimum number of selected data type service instances.